Firebase 设计师分享: 如何推进产品设计改版
作者: Maple, Designer, Google
Crashlytics 是一个崩溃报告工具，可以帮助移动应用开发者了解应用崩溃的原因。如果您是从 Fabric 时代过来的 Crashlytics 老用户的话，应该能一眼看出来前后两版设计中的关键区别:
△ 上图: Fabric 时代的 Crashlytics，下图: Firebase 时代的 Crashlytics
了解 Crashlytics
https://firebase.google.cn/products/crashlytics/
随着 Fabric 被 Google 收购，我的团队于 2017 年 1 月加入了 Firebase。此次收购的目标之一便是将 Crashlytics 整合进 Firebase。这意味着使用 Firebase 的风格体系对我们的产品进行改版和重构: Firebase 采用 Material Design 设计风格，且拥有非常独特的视觉设计体系。
这是个大工程，而我认为这是一个对用户体验进行整体性再思考的好机会，而不仅仅只是把原有的功能用新的 UI 包装一遍。Crashlytics 是一款深受喜爱的产品，但自 2011 年创建以来在设计方面 "欠账" 很多。很多用户向我们反映，他们在使用的过程中遇到了困难，或是找不到已经存在的功能。我们的团队也很难弄清楚应该在哪里放置新功能，因为对我们自己和用户而言，产品都缺乏明确的信息架构。现在是重新设计的时候了。
但首先，我需要力证彻底改版的必要性。
△ "产品改版可不是小事" / 图片来自: imgflip.com
一款产品的彻底改版可没说起来那么容易。这需要经历相当长一段时间才能理解用户，了解他们使用产品的方式，以及他们遇到的问题。在开始重新设计之前，我们需要获取这些方面的准确信息，以确保团队正在解决的问题是正确的问题，并且让大家始终锁定这些项目目标。
第一步: 了解用户
第一步是收集信息。我和很多人做了深入的交流，包括在 Crashlytics 团队中待了很多年的人，还有我们的开发者关系团队、用户研究人员，当然还有我们的用户。在弄清楚应该如何改善用户体验之前，我首先需要了解人们使用 Crashlytics 的原因和方式。
幸运的是，我的产品经理 Jason St. Pierre 在 Crashlytics 项目工作了 5 年多，经常与用户交谈，他对各种各样的用户群体如何使用 Crashlytics 有深刻的理解。他确定了 4 个最关键的 Crashlytics 用户场景:
监控新发布的应用版本的稳定性
检查应用稳定性
给崩溃的修复工作划分优先级
调试客户反馈过来的问题
△ Crashlytics 中最关键的用户场景: 监控新发布的应用版本的稳定性
这只是开始。接下来我将不同的用户角色 (Persona) 代入到这套流程中，发现所有 4 个场景中都存在一条暗线: "检查与修复" 子流程。我与团队分享了这些流程，并根据需要重新梳理了它们。这些流程让 Crashlytics 团队的所有成员从根源上了解了用户使用我们产品的方式。
△ "检查与修复" 子流程在核心用户场景里反复出现
第二步: 了解用户痛点
在对人们使用产品的方式达成一致的理解后，我们需要了解现有用户体验中的痛点。Crashlytics 团队的协作性非常强，所有人都在致力于为用户构建良好的体验。我想设法让他们参与到改版设计的过程里，这样就比我单方面地向他们分享设计概念并收集反馈要好，而且更体现协作精神。另外在设计过程中，产品团队拥有很多富有价值的上下文信息，毕竟他们中的许多人这么多年来一直在研究改进这个产品。
Crashlytics 团队的许多人都从各自的角度提到了首页控制面板需要改进。为了利用他们的知识，我决定进行一系列内部用户调研。我的目标是，基于我们多年来从用户那里听到的反馈，来了解用户体验中最大的痛点是什么。
我把 Crashlytics 的控制面板打印并裁成了单个的小块，然后逐一和团队成员们展开讨论，我要求他们重新组合这些小块，从而打造出新的控制面板，而且还要明确说出他们这么组合的思路。
△ 团队成员使用纸模重新排列设计控制面板
△ 有一些纸模设计甚至还 "加了料"，因为现有的模块无法满足需求
这样做非常有用。它不仅有趣 (毕竟如今的设计师日常工作时几乎接触不到纸模)，还能让我看到每个人眼中痛点的位置，同时让他们免受任何固有印象的影响，从而使我更容易定位反复出现的那些问题。例如，每个人都专注于改进过滤器，并改善信息层次架构。我还从开发者关系团队了解到哪些功能让用户感到难以使用，或者压根就很难找到这些功能。
我将这些信息分享给了团队，并在一个设计文档里对改版设计的工作进行了细分 (这个文档会持续迭代)。我还与团队一起设置了每周设计签到机制，以便分享设计更新，并确保他们能一直跟进改版设计的过程。
△ 设计文档里的一页，强调了重点设计课题
第三步: 定义设计课题
在了解了用户的使用目标和痛点之后，设计课题自然会更加清晰。我从纸模阶段以及团队对话中吸收了大量的信息，并据此总结出了主要的设计课题。
课题1: 用户很难轻松查看自己最关心的数据
从一个细节可以看出来问题: 大多数用户在我们的首页面板上做的第一个操作是向下滚动。因为他们正在寻找的信息往往位于页面中靠下的位置，或需要多次点击才能到达。众多不太重要的功能淹没了真正重要的信息。
△ 出错报告详情页就是用户不得不 "多点几下" 才能看到的页面
问题2: 用户不知道某些功能已经存在
曾经有一个用户要我添加一个功能，来记录应用中导致崩溃的事件日志。但这个功能已经存在于首页面板中，只是隐藏在 UI 里而已。许多用户都向我们的客服团队提出了类似的问题。这些情况也反映了团队面临的普遍问题: 难以确定应该在哪里放置功能。
△ 日志功能早就有了，但只是一个不显眼的 "开关"
上面两个设计课题之所以会出现，从本质上讲，还是因为我们的产品信息架构不明确。所以我向利益相关者提出了应该解决的主要问题，由于这些人一直都在参与上述的设计过程，因此我提出的这些改进计划很容易就被认可了，而且在具体推进时也轻松了很多。
第四步: 迈向成功
现在我们的状态是: 团队正式认可了改版的必要性。他们了解了用户遇到的问题，并就用户体验的哪些部分需要改进达成了一致。成功了一半！
接下来的工作自然就是重新设计产品面板。在接下来的几个月内我们组织了大量的头脑风暴、协作、设计签到 / 讨论，以及用户测试。
说服整个团队进行产品设计改版涉及到大量的利益权衡工作。作为设计师，您可能会认定产品显然需要重新设计，但这毕竟只是一家之言，到了需要团队决策的时候您会发现一个巴掌根本拍不响。重新设计产品是一个团队的工作，全体成员都必须意识到这么做的必要性才行。所以，如果您不了解产品目前是怎样被使用的，就谈不上扎实有效地进行针对性的重新设计。
通过深刻理解 Crashlytics 用户、他们的痛点和他们的问题，我更好地重新设计了产品。通过带着其他人经历全过程，整个团队也得以更好地了解用户，并满足他们的需求。经过数月的努力和与用户的交流，我们最终成功地将 Crashlytics 进行了改版，并有机地整合进了 Firebase。在这个过程中，新功能上线以及信息架构的重组做到了两全其美。
最后，让我展示一下 Crashlytics 改版后我最喜欢的设计 "甜点":
△ "抓住 bug 啦！"——解决 bug 之后的小动画
您的产品在上线后有经历过彻底的改版吗？在改版中遇见了哪些问题？或者收获了哪些经验？欢迎在评论区和我们分享。
推荐阅读